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Abstract 
This document extends the Multi-threaded Routing Toolkit (MRT) export 
format for Border Gateway Protocol (BGP) routing information by 
supporting the advertisement of multiple paths in BGP extensions. 
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1. Introduction 


The MRT record format [RFC6396] was developed to provide researchers 
and engineers a means to encapsulate, export, and archive routing 
protocol transactions and RIB snapshots. 


The Advertisement of Multiple Paths in BGP [RFC7911] defines a BGP 
extension to allow the advertisement of multiple paths for the same 
address prefix without the new paths implicitly replacing any 
previous ones. 


This document contains an optional extension to the MRT format 
[RFC6396] and introduces additional definitions of MRT subtype fields 
to permit representation of multiple path advertisements [RFC7911]. 


2. Rationale 


MRT parsers are usually stateless. In order to parse BGP messages 
that contain data structures that depend on the capabilities 
negotiated during the BGP session setup, the MRT subtypes are 
utilized. The Advertisement of Multiple Paths [RFC7911] extension 
for BGP alters the encoding of the BGP Network Layer Reachability 
Information (NLRI) format for withdraws and announcements. 
Therefore, new BGP4MP/BGP4MP_ET subtypes as defined in [RFC6396] are 
required to signal to an MRT parser how to parse the NLRI. 


In Section 4.3 of the MRT specification [RFC6396], RIB subtypes are 
specified. Prefix length and prefix fields are encoded in the same 
manner as the BGP NLRI encoding. In order to support Path Identifier 
information as defined in [RFC7911], new subtypes need to be added. 


The following two sections define the required subtypes. 
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3. MRT Subtypes for Types BGP4MP/BGP4MP_ET 
This document defines the following new subtypes: 


o BGP4MP_MESSAGE_ADDPATH 


o BGP4MP_MESSAGE_AS4_ADDPATH 
o BGP4MP_MESSAGE_LOCAL_ADDPATH 
o BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH 
The fields of these message types are identical to the equivalent 
non-additional-path versions specified in Section 4.4 of [RFC6396]. 
These enhancements continue to encapsulate the entire BGP message in 
the BGP message field. 

4. MRT Subtypes for Type TABLE_DUMP_Vv2 


This document defines the following new subtypes: 


o RIB_IPV4_UNICAST_ADDPATH 


o RIB_IPV4_MULTICAST_ADDPATH 

o RIB_IPV6_UNICAST_ADDPATH 

o RIB_IPV6_MULTICAST_ADDPATH 

o RIB_GENERIC_ADDPATH 

The fields of these message types are identical to the equivalent 
non-additional-path versions specified in Section 4.3 of [RFC6396]. 
However, for the case of the 4 AFI/SAFI-specific RIB subtypes, the 


existing RIB Entries field is redefined as detailed in the sections 
below. 
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4.1. AFI/SAFI-Specific RIB Subtypes 


In order to preserve the record compaction achieved by using the most 
common subtypes and allow multiple RIB Entries to be stored ina 
single TABLE_DUMP_V2 record, the existing RIB Entries field is 
redefined for use within the new AFI/SAFI-specific RIB subtypes 
defined by this document as follows: 


0 k 2 3 

Ob 22. 3) 4-8 6°70 8 98-0 ML, 28 4b 6 F898 OT S23? 4 6. 7B 29° «08 id 
$oF FF iti ti tipi p gigi pitti tipi pipe p epg HHHH 
| Peer Index | 
$oFoF Fat ti tipi p igi ppt titi pi pipe p epg HHHH 
| Originated Time | 
+-+-+-+-+-+-+-+-+-+-+++ +++ 
| Path Identifier | 
+-+-+-+-+-+-+-+-+-+-+++ t titi tigi pepe HHHH 
| Attribute Length | 
$oPF Fito tipi pi pip gigi titi titi tigi pepo HHHH 
| BGP Attributes... (variable) 
$oF-F Fito tipi pi gigi gigi titi titi gi pipe g gig gig titted 


Figure 1: RIB Entries for AFI/SAFI-Specific RIB Subtypes with 
Support for Additional Paths 


This adds a field to the RIB Entries record to store the Path 
Identifier when used with the RIB_IPV4_UNICAST_ADDPATH, 
RIB_IPV4_MULTICAST_ADDPATH, RIB _IPV6_UNICAST_ADDPATH, and 
RIB_IPV6_MULTICAST_ADDPATH subtypes. 


4.2. RIB _GENERIC_ADDPATH Subtype 
The fields of this subtype are identical to the equivalent non- 
additional-path versions specified in Section 4.3.3 of [RFC6396]. 
These fields continue to encapsulate the raw and additional-path- 
enabled AFI/SAFI/NLRI in the record, and the raw attributes in the 
RIB Entries. 


For clarity, the RIB Entries in this subtype are not redefined. 
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5. IANA Considerations 


IANA has assigned the subtype codes defined below in the "Multi- 
threaded Routing Toolkit (MRT)" registry 
<https://www.iana.org/assignments/mrt>. 


5.1. BGP4MP/BGP4MP_ET Subtype Codes 


The following have been registered in the "BGP4MP Subtype Codes" and 
"BGP4MP_ET Subtype Codes" registries: 


8 BGP4MP_MESSAGE_ADDPATH (RFC 8050) 


T 


9 BGP4MP_MESSAGE_AS4_ADDPATH (RFC 8050) 

10 BGP4MP_MESSAGE_LOCAL_ADDPATH (RFC 8050) 

11 BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH (RFC 8050) 
5.2. TABLE_DUMP_V2 Subtype Codes 


The following have been registered in the "TABLE_DUMP_V2 Subtype 
Codes" registry: 


8 RIB_IPV4_UNICAST_ADDPATH (RFC 8050) 

9 RIB_IPV4_MULTICAST_ADDPATH (RFC 8050) 

10 RIB_IPV6_UNICAST_ADDPATH (RFC 8050) 

11 RIB_IPV6_MULTICAST_ADDPATH (RFC 8050) 

12 RIB_GENERIC_ADDPATH (RFC 8050) 

6. Security Considerations 

It is not believed that this document adds any additional security 
considerations. However, the security considerations of [RFC6396] 
are equally applicable to this document, because this document 
permits the export of more detailed routing data. 
An organization that uses the MRT format to store their BGP routing 
information should be aware that supporting these extensions permits 


more detailed network path information to be stored and should 
consider the implications of this within their environment. 
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An organization that peers with public BGP collectors and enables the 
capability for additional paths on a peering session should be aware 
that it is exporting not only its best paths, but potentially other 
paths within its networks. The BGP peer should consider any and all 


implications of exposing this additional data. 
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